home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 5253 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  2.9 KB
  1. Path: cs.vu.nl!sun4nl!ittpub!ittpub!nntp
  2. Newsgroups: comp.lang.c++
  3. Subject: Re: How to handle error in constructor
  4. Message-ID: <1996Feb2.170821.1768@ittpub>
  5. From: wil@ittpub.nl (Wil Evers)
  6. Date: 2 Feb 96 17:08:20 WET
  7. References: <4eo6n6$rbp@cnn.exu.ericsson.se>
  8. Distribution: world
  9. Nntp-Posting-Host: lintilla
  10.  
  11. In article <4eo6n6$rbp@cnn.exu.ericsson.se> ebumow@ebu.ericsson.com  
  12. (Mickey Williams 66753) writes:
  13. > In article 5EG@teslab.lab.oz.au,  andrew@teslab.lab.oz.au (Andrew  
  14. Phillips) writes:
  15.  
  16. > >I'm converting and enhancing a simple program in C to C++. Without
  17. > >going into too much detail I have a class that represents a file on
  18. > >disk. The contructor opens the file, but what should it do if the file
  19. > >cannot be opened?  The C program just calls fopen() tests the return
  20. > >value and if there's an error it prints a message and exits.
  21. > 
  22. > >In C++ I thought to set a flag in the constructor and have a member
  23. > >function that tests the flag to see if the file was opened correctly.
  24. > 
  25. > In practice, it is impossible to ensure that this works as intended.
  26. > Also, every user of this class must understand this error handling
  27. > mechanism. On the other hand, exceptions are part of the standard, so
  28. > throwing one of the standard exceptions should be much safer.
  29.  
  30. There may be alternatives to throwing an exception here. Basically, disk  
  31. file objects should behave reasonbly when the constructor couldn't open  
  32. the requested file: for instance, instead of just assuming the fopen()  
  33. succeeded, they could report failure when someone tries a read or write  
  34. operation.   
  35.  
  36. > >This seems rather inelegant -- I guess exceptions would be the elegant
  37. > >way but seem like overkill for such a simple program.
  38. > 
  39. > Elegant, schmelegant. It's the correct tool for the job.
  40. > [example deleted]
  41.  
  42. Is it? Suppose, for instance, that I want to check for some parameter  
  43. settings in an optional configuration file. Here, all I need to know is if  
  44. there are any options to set. If there are none, I don't care why, so if  
  45. the first read on the non-existing file simply returns EOF, I will be  
  46. perfectly happy.
  47.  
  48. If the disk file class further provides me with the option of telling me  
  49. if the file could be opened - and, if not, why not, then I can decide for  
  50. myself how sophisticated my error handling will be. 
  51.  
  52. The problem with exceptions is, that I'm *required* to handle them or else  
  53. my program will die - even if failure to open a file is nothing to be  
  54. upset about. A decent disk file class should at least give me the option  
  55. to say 'no thanks, no exceptions for me this time.'
  56.  
  57. IMHO exceptions are useful for handling major disasters, not for small  
  58. inconveniences. Classes simply throwing an exception from their  
  59. constructors because the class's programmer is too lazy to keep the  
  60. object's state consistent in the face of such a failure are a nuisance at  
  61. best, and could easily cause severe paranoia for the class's users.
  62.  
  63. - Wil
  64.  
  65.